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ABSTRACT.  We  are  in  the  process  of  devebping  Marvel,  a  knowledge-based  programming 
environment  that  assists  multi-programmer  software  development  teams  in  performing  and  coor¬ 
dinating  their  activities.  During  the  design  of  Marvel,  we  discovered  that  the  granularity  to  which 
logical  entities  are  refined  in  its  software  database  andlhe  granularity  with  which  its  software  tools 
process  the  entities  and  report  their  results  to  the  human  users  have  a  strong  impact  on  the 
degree  of  intelligence  that  can  be  exhibited,  as  well  as  on  the  friendliness  and  performance  of  the 
environment.  In  thiaa-pnper,  we  describe  the  many  choices  among  alternative  granularities  and 
explain  the  decisbnslwe  made  during  the  design  of  Marvel.  s.-_ 

Jj  j  I-  w  I  .  j 

1 1ntroduction 

We  are  currently  developing  a  knowledge-based  programming  environment  called 
ProfessorMarvel,  or  Marvel  for  short.2  Marvel  is  knowledge-based  in  the  sense  that  it  under¬ 
stands  the  logical  entities  and  the  activities  involved  in  the  software  development  process.  It  is  an 
environment  rather  than  a  software  tool  because  it  actively  participates  in  the  software  develop¬ 
ment  process  rather  than  remaining  passive  until  explicit  demands  are  made  by  its  users.  The 
primary  functions  of  Marvel  are  (1)  to  interactively  answer  queries  about  the  current  status  of  the 
development  effort  and  the  relationships  among  components  of  the  target  software  system  and 
(2)  to  automatically  perform  bookkeeping  chores  and  simple  development  activities.  This  is  in 
contrast  to  some  other  intelligent  assistance  systems  such  as  the  Programmer’s  Apprentice  (also 
known  as  KBEmacs)  [30],  CHI  (previously  PSI)  [24]  and  the  Formalized  System  Development 
system  (FSD)  [2],  which  focus  on  the  separate  problem  of  automatic  programming  and  program 
synthesis. 

Unlike  most  other  knowledge-based  programming  environments,  Marvel  supports  multi¬ 
programmer  software  development  teams  as  well  as  individual  programming  efforts.  For  ex¬ 
ample.  it  includes  facilities  corresponding  to  Build  [7]  and  SCCS  [22]  to  coordinate  simultaneous 
and  sequential  activities  among  multiple  developers.  However,  Marvel  approaches  these 
facilities  in  a  participatory,  knowledge-based  fashion  that  enables  it  to  automatically  invoke  the 
tools  at  the  proper  times  without  human  intervention. 

Marvel  is  our  second  multi-user  programming  environment.  Our  first  system,  called  Smile 
[25, 9],  was  developed  several  years  ago  to  support  our  research  on  the  Gandalf  project  [20].  It 


'The  research  presented  in  this  paper  was  conducted  while  Dr.  Kaiser  was  a  Visiting  Computer  Scientist  at  the 
Software  Engineering  Institute,  Camegie-Mellon  University,  Pittsburgh,  PA. 

aProfessor  Marvel  was  the  (Kansas)  name  of  the  man  behind  ihe  curtain  in  the  movie  77>e  Wizard  of  Oz 


has  since  been  used  extensively  by  other  projects  at  Camegie-Mellon  University,  at  AT&T  Beil 
Laboratories  and  at  the  University  of  Pisa,  and  has  been  distributed  to  approximately  forty  sites. 
Smile  was  implemented  in  C  and  runs  on  Unix™.  Smile  presents  a  fileless  environment  to  its 
users,  answers  implicit  and  explicit  queries,  and  automatically  invokes  various  tools  for  its  users. 
However,  Smile’s  knowledge  is  hardcoded  into  the  environment  and  is  not  extensible;  Smile  does 
not  realty  ‘understand’  what  it  is  doing. 

Although  we  found  Smile  very  useful,  and  in  fact  relied  on  it  for  the  implementation  and  main¬ 
tenance  of  most  of  our  research  projects,  we  became  convinced  that  an  environment  that  did 
understand  what  it  was  doing  could  provide  much  more  valuable  assistance.  Because  of  this,  we 
have  based  our  design  of  Marvel  on  an  architecture  for  intelligent  assistance  that  consists  of  an 
objectbase  and  a  model  of  the  software  development  process.  The  objectbase  maintains  all 
software  objects,  including  tools  such  as  the  editor  and  the  compiler.  The  objectbase  provides 
Marvel  with  insight  into  the  various  classes  of  objects  and  the  relationships  among  objects,  such 
as  one  object  is  a  component  of  another  and  a  particular  object  may  be  applied  to  another  object 
to  produce  a  third  object. 

The  model  imposes  a  structure  on  programming  activities.  It  consists  of  an  extensible  collection 
of  production-like  rules  that  specify  the  particular  conditions  that  must  exist  for  particular  activities 
to  be  carried  out.  Metarules  permit  Marvel  to  understand  the  rules  and  support  opportunistic 
processing,  where  the  environment  can  perform  simple  activities  automatically,  such  as  satisfying 
the  preconditions  of  an  activity  and  then  carrying  out  the  activity  when  it  knows  the  results  of  the 
activity  wilt  soon  be  required  by  a  user. 

Insight  and  opportunistic  processing  are  the  topic  of  another  paper  [15],  and  will  be  discussed 
only  briefly  in  this  paper.  The  focus  of  this  paper  is  the  granularity  issues  that  arose  during  our 
long  experience  with  Smile  and  during  the  subsequent  design  of  Marvel.  In  particular,  we  ran 
into  several  problems  regarding  the  appropriate  refinement  of  logical  entities  to  be  maintained  as 
separate  software  objects  and  the  units  appropriate  both  for  tools  and  for  reporting  the  results  of 
tool  processing  to  the  users.  Choice  of  granularity  affects  the  capabilities  of  the  intelligent  assis¬ 
tant,  the  friendliness  vs.  intrusiveness  of  the  programming  environment  and,  of  course,  perfor¬ 
mance  and  responsiveness.  We  believe  that  discussion  of  these  issues,  including  an  explanation 
of  the  decisions  we  made  regarding  Marvel,  will  prove  useful  to  other  researchers  who  are  in  the 
process  of  building  knowledge-based  programming  environments. 

In  the  rest  of  this  paper,  we  briefly  explain  the  underlying  basis  for  intelligent  assistance  utilized 
by  Marvel.  We  then  address  three  areas  of  granularity  issues:  the  granularity  of  structure  in  the 
objectbase,  its  impact  on  tools,  and  the  granularity  of  processing  automatically  performed  by  the 
environment.  We  conclude  by  summarizing  the  significance  of  these  issues  for  achieving  intel¬ 
ligent  assistance  for  software  development. 


2  A  Basis  for  Intelligent  Assistance 

The  distinguishing  feature  of  an  intelligent  assistant  is  that  it  understands  what  It  is  doing  [31]. 
We  believe  that  both  an  object  base  and  a  model  of  the  software  development  process  are  prere¬ 
quisites  to  intefligent  assistance.  An  assistant  cannot  understand  why  it  performs  particular  ac¬ 
tivities  unless  it  knows 

•  the  properties  of  the  objects  it  manipulates, 

•  the  capabilities  of  certain  objects  (programmers  and  tools)  to  manipulate  other  ob¬ 
jects, 

•  the  preconditions  required  by  each  activity, 

•  the  results  or  postconditions  of  each  activity. 

Therefore,  Marvel  includes  a  general  objectbase  that  maintains  software  entities  and  tools,  and 
an  extensible  collection  of  rules  that  describe  the  preconditions  and  postconditions  of  software 
development  activities. 

2.1  The  Objectbase 

There  are  several  possible  forms  for  our  objectbase  to  take.  To  maximize  flexibility,  we  chose  an 
objectbase  similar  to  the  objectbases  of  object-oriented  programming  languages,  such  as  Loops 
[26].  In  particular,  we  adopted  their  support  for  multiple  inheritance  and  active  values.  The  same 
concepts  are  found  in  the  objectbases  supported  by  other  knowledge-based  programming  en¬ 
vironments,  such  as  the  CommonLisp  Framework  (CLF)  [3]  and  Refine™  [24]. 

In  the  Marvel  objectbase,  each  object  is  an  instance  of  a  class,  which  defines  certain  attributes 
of  each  object  and  inherits  other  attributes  from  its  superclass(es).  Some  attributes  define  the 
relationships  among  the  objects,  while  others  trigger  activities  when  they  are  accessed  and/or 
updated.  The  software  development  activities  applicable  to  the  members  of  a  class  are  defined 
as  methods  for  the  class. 

Marvel  presents  a  lifeless  environment',  exposing  its  users  only  to  the  logical  structure  of  the 
target  software  system.  As  far  as  the  users  are  concerned,  the  environment  consists  of  a  set  of 
typed  and  interconnected  software  objects  that  represent  both  the  system  and  its  history  of 
development.  Object  types  include  module,  procedure,  type,  design  description,  user  task  (or 
development  step),  user  manual,  etc.  Typing  of  these  objects  permits  Marvel  to  provide  an 
object-oriented  user  interface  similar  to  the  Smalltalk-80™  environment  [11].  This  means  that  the 
environment  makes  available  to  each  user  only  those  commands  that  are  relevant  to  the  object 
under  consideration. 

The  interconnections  among  software  objects  represent  the  logical  structure  of  the  system.  The 
more  detailed  the  structure,  the  more  information  is  available  for  browsing  and  querying,  and  the 
more  Marvel  can  deduce  which  activities  it  can  suitably  perform  and  understand  those  tasks  that 
the  users  carry  out.  These  issues  are  addressed  in  Section  3. 


2.2  The  Model 


There  are  also  several  possible  forms  for  the  rules  we  use  to  model  the  software  development 
process.  Again  to  maximize  flexibility,  we  chose  a  style  of  rule  developed  in  the  program  verifica¬ 
tion  community.  Each  software  activity  is  associated  with  preconditions  and  postconditions,  as 
defined  by  Hoare  [14],  The  postconditions  of  an  activity  may  satisfy  the  preconditions  of  future 
activities. 

Our  rules  are  similar  to  the  production  rules  of  Ops5  [5]  and  the  automation  rules  of  CLF  (2]  in 
that  each  rule  has  both  a  condition  and  action.  When  the  condition  is  true,  or  satisfied,  then  the 
action  may  be  carried  out.  Our  rules  are  different  from  productions  in  that  the  action  is  divided 
into  two  parts,  an  activity  and  the  postconditions.  Because  we  have  added  postconditions  to  our 
rules,  we  refer  to  the  original  conditions  as  preconditions.  We  use  the  activity  part  of  a  rule  to 
represent  an  integral  software  development  task.  For  example,  "compile  module"  is  one  activity 
and  "edit  procedure”  is  another.  The  preconditions  of  "compile  module"  are  that  the  module  is  not 
compiled  and  that  all  its  components  have  been  analyzed  without  errors;  there  are  two  possible 
postconditions,  exactly  one  of  which  is  true:  the  module  was  compiled  correctly  and  the  compila¬ 
tion  detected  errors.  Preconditions  and  postconditions  are  written  as  well-formed  formulas  (wffs) 
in  the  first  order  predicate  calculus. 

Our  rules  are  maintained  in  a  knowledgebase  that  also  includes  metarules,  which  permit  Marvel 
to  perform  activities  and  explain  activities  in  terms  of  the  rules.  One  metarule  supports  forward 
chaining.  If  the  preconditions  of  a  rule  are  satisfied,  then  Marvel  may  perform  the  activity;  the 
postconditions  may  satisfy  the  preconditions  of  other  rules,  which  may  then  be  applied.  Another 
metarule  defines  backward  chaining;  If  a  user  requests  a  particular  activity,  then  Marvel  may 
attempt  to  satisfy  its  preconditions;  this  often  requires  the  environment  to  first  perform  other  ac¬ 
tivities  whose  postconditions  match  the  preconditions  of  the  original  rule.  Marvel  determines 
when  to  apply  a  particular  metarule  by  employing  strategies,  which  are  collections  of  rules  and 
metarules. 

These  and  other  metarules,  together  with  the  rules  and  the  objectbase,  support  insight  and  op¬ 
portunistic  processing.  One  simple  example  of  insight  occurs  when  a  user  invokes  the  ‘change 
procedure"  command,  which  enables  editing  of  both  the  specification  (header)  and  body  of  a 
particular  procedure.  Marvel  uses  the  results  of  its  incremental  analysis  of  dependencies  among 
software  components  to  inform  the  user  of  the  potential  consequences  of  this  action;  for  example, 
each  calling  procedure  will  have  to  be  modified  if  the  number  or  order  of  the  parameters  are 
changed.  A  simple  example  of  opportunistic  processing  occurs  after  a  user  completes  the 
"change  procedure"  command  by  writing  out  the  procedure  from  the  editor.  Marvel  notices  that 
a  postcondition  of  this  activity  is  that  the  procedure  is  not  analyzed,  which  is  also  the  precondition 
of  the  "analyze  procedure"  activity,  Marvel  uses  forward  chaining  to  automatically  update  its 
incremental  analysis. 

A  full  treatment  of  our  objectbase  and  model  and  their  application  to  insight  and  opportunistic 
processing  is  given  in  [15]. 


3  Granularity  of  Structure 

The  degree  of  Intelligence  that  can  be  demonstrated  by  Marvel,  or  any  knowledge-based  pro¬ 
gramming  environment,  is  intimately  tied  to  the  granularity  of  independent  entities  maintained  by 
its  objectbase  and  to  the  granularity  of  the  processing  tools  it  has  available.  The  granularity  of 
structure  determines  to  what  extent  the  target  software  system  is  decomposed  into  separately 
stored  entities.  Separate  storage  may  take  the  form  of  independent  objects  or  of  attributes  of 
other  objects.  An  appropriate  choice  of  decomposition  is  influenced  by  several  factors,  including 
the  need  for  separately  recognizable  logical  entities,  viewing  and  manipulation  of  the  structure  by 
the  users,  and  space/time  tradeoffs  [19]. 

It  is  desirable  to  have  the  logical  entities  of  the  target  system  separately  accessible  for  several 
reasons.  In  the  first  place,  an  object  or  attribute  can  be  referenced  from  other  parts  of  the 
system,  while  it  is  not  possible  to  refer  directly  to  only  a  portion  of  the  information  within  an 
attribute.  Examples  of  such  entities  are  modules,  procedures,  macros,  and  global  variables  in  the 
program  domain,  sections  and  subsections  in  the  document  domain,  and  plans,  tasks,  and 
developers  in  the  management  domain. 

Logical  entities  depend  on  each  other  in  various  ways,  and  the  interconnection  structure  must  be 
accessible  to  maintain  a  consistent  representation  of  the  target  system.  These  connections  are 
viewed  and  manipulated  both  by  the  human  users  and  by  the  environment.  If  the  entities  are 
accessible  as  separate  objects,  then  the  connections  can  be  represented  as  relations  among 
these  objects.  Examples  include  actual  use  dependency  among  software  components  such  as 
procedures,  macros  and  variables,  intentional  use  dependency  as  expressed  through  export  and 
import  clauses  of  modules,  compilation  order,  or  referential  use  such  as  reference  to  a  section  or 
a  citation  in  a  document. 

Status  information  is  associated  with  particular  logical  entities.  Status  can  represent  the  need  to 
or  the  result  of  processing  an  entity,  such  as  analysis  of  a  procedure,  code  generation  for  a 
module,  or  running  a  section  of  a  document  through  the  document  processor.  It  can  also  indicate 
coordination  information  among  multiple  users  and  between  users  and  tools,  i.e.,  synchronization 
and  version  information  [28].  Marvel  stores  status  information  as  attributes  of  objects. 

The  set  of  logical  entities  attributed  with  status  information  determines  to  some  extent  the  degree 
of  intelligence  that  can  be  built  into  the  facilities  provided  by  a  knowledge -based  programming 
environment.  For  example,  to  support  'smart  recompilation’  [29, 23],  it  is  necessary  to  store 
status  information  about  each  intermodule  symbol  definition  and  use.  This  enables  Marvel  to 
recompile  only  those  entities  that  actually  use  modified  symbols,  as  opposed  to  recompiling  all 
modules  that  depend  in  any  way  on  the  module  whose  interface  has  changed.  In  contrast,  Smile 
supports  import  and  export  clauses,  but  does  not  permit  more  detailed  relations  among  individual 
components,  so  it  is  not  able  to  provide  this  kind  of  intelligent  processing. 

It  may  be  desirable  for  users  to  navigate  and  manipulate  the  target  system  according  to  the 
structural  units  represented  by  logical  entities.  Syntax-directed  editors  [27]  usually  support  cursor 
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movement  and  manipulation  at  the  language  construct  level;  Rational™  [1]  takes  this  to  an  ex¬ 
treme  by  performing  all  processing  in  terms  of  the  Diana  [6]  representation  of  Ada™  programs. 
Even  text  editors  support  a  certain  amount  of  structure,  such  as  the  electric-lisp  mode  in  Emacs 
[13]  recognizing  matching  parentheses.  Graphical  editors  support  manipulation  of  basic  graphi¬ 
cal  symbols  such  as  lines,  circles  and  icons  as  well  as  composite  graphical  units.  Word  process¬ 
ing  systems  support  character,  word,  sentence  and  paragraph  manipulation.  Marvel  supports 
viewing  at  the  level  of  objects,  using  certain  of  their  attributes  as  paths  that  can  be  followed  by  the 
browser  to  other  objects. 

User  actions,  especially  modifications,  have  different  effects  for  different  logical  entities.  For 
example,  editing  of  a  comment  does  not  affect  analysis  or  code  generation  but  is  relevant  to 
updating  of  hardcopy  listings,  whereas  modification  to  a  design  specification  not  only  affects  other 
parts  of  the  design,  but  also  the  implementation.  Thus,  Marvel  provides  object-oriented  com¬ 
mands  to  reflect  these  distinctions.  Marvel  can  then  recognize  a  user's  focus  of  attention  as  well 
as  the  extent  of  his  or  her  modifications  in  order  to  be  able  to  provide  insight  and  to  intelligently 
and  effectively  restore  consistency  of  the  target  system.  Smile's  more  primitive  user  interface 
requires  the  user,  for  example,  to  give  the  "edit  procedure"  command  to  edit  the  body  of  a  proce¬ 
dure  and  the  distinct  "change  procedure"  command  to  edit  its  specification  (header). 

4  Impact  of  Structure  Granularity  on  Tools 

The  question  arises  as  to  the  choice  of  the  smallest  logical  entity  that  should  be  separately 
represented  as  an  object.  The  answer  must  consider  that  there  are  two  ways  to  have  logical 
entities  separately  recognizable.  One  is  by  analyzing  a  'larger*  entity  that  is  stored  as  a  separate 
object  in  the  objectbase,  and  deriving  the  ‘smaller’  entities  as  needed.  The  alternative  is  to 
represent  each  logical  entity  as  a  separate  object.  The  appropriate  choice  is  a  tradeoff  between 
the  proliferation  of  objects  and  explosion  of  information  to  be  stored  on  the  one  hand  and 
reprocessing  of  information  on  the  other.  This  manifests  itself  in  a  variety  of  ways. 

Tools  provided  as  part  of  a  knowledge-based  programming  environment  may  require  a  special 
interface  to  the  objectbase  as  they  may  not  be  able  to  cope  directly  with  composite  objects.  For 
example,  a  compiler  requires  adaptation  to  be  able  to  process  modules  as  separate  compilation 
units  when  they  consist  of  sets  of  references  to  objects  representing  imported  entities  and  a 
composition  of  objects  representing  the  procedures,  etc.,  comprising  the  module.  It  is  preferable 
to  bring  in  existing  tools  without  modifications;  DSEE™[18]  does  this  for  version  control  by 
providing  a  virtual  interlace  between  each  tool  and  the  version  manager.  We  would  like  to  do  this 
in  the  general  case,  so  Marvel  provides  multiple  views  corresponding  to  the  normal  interfaces  of 
the  tools  [10].  Smile  does  not  support  views,  and  so  is  forced  to  store  objects  in  the  form  ex¬ 
pected  by  its  tools;  this  sometimes  results  in  duplication  of  information  when  the  same  kind  of 
object  is  processed  by  multiple  tools. 

The  status  information  of  all  components  of  a  composite  object  may  be  accessed  frequently.  For 
example,  the  result  of  analysis  of  all  components  of  a  module  must  be  positive  before  code 


generation  should  be  done.  Marvel  can  either  compute  the  composite  status  value  every  time  it 
is  desired  or  it  can  cache  the  value  in  the  module  object  and  maintain  it  incrementally,  as  com¬ 
ponents  are  modified  and  re-analyzed,  using,  for  example,  finite  differencing  techniques  [12]. 

Another  example  of  status  information  is  the  error  messages  resulting  from  unsuccessful 
processing.  Users  tend  to  query  them  at  times  other  than  the  time  they  are  produced  by  the 
processing  tool,  except  when  the  activity  is  performed  on  user  demand.  Marvel  stores  error 
messages  explicitly  for  strongly-typed  languages,  since  recomputation  is  costly. 

Interconnection  information,  such  as  actual  use,  may  not  require  explicit  representation,  but  this  is 
orthogonal  to  whether  the  information  is  explicitly  stored  or  dynamically  determined.  In  other 
words,  an  attribute  can  be  calculated  only  when  needed,  and  information  can  be  stored  as  part  of 
some  composite  attribute  rather  than  separately.  One  example  of  the  first  category  is  use  depen¬ 
dency  of  local  variables.  This  is  rarely  queried  because  all  use  sites  are  often  displayed  simul¬ 
taneously.  A  user  can  visually  search  or  use  a  viewer  (editor)  search  command.  Where  explicit 
representation  is  necessary,  the  environment  may  explicitly  store  only  the  module  in  which  an 
exported  procedure  is  actually  used  (because  the  whole  module  has  to  be  recompiled)  and 
dynamically  analyze  the  module  when  queried  about  the  calling  procedures,  or  it  may  explicitly 
store  the  procedure  that  calls  the  exported  procedure  but  not  every  catlsite  within  the  procedure 
as  those  are  easily  found  by  direct  search  when  needed.  Smile  follows  the  former  strategy,  but 
the  response  time  is  widely  variable  and  sometimes  unacceptable,  so  Marvel  follows  the  latter 
course. 

An  objectbase  permits  tracking  of  modifications  to  objects.  Representing  logical  entities  as 
separate  objects  at  appropriate  granularities  eliminates  additional  processing  such  as  recognition 
of  changes  within  regions  of  an  object  by  the  editor  or  content  comparison  algorithms  (such  as 
Diff  [28]).  For  example,  procedures  may  be  represented  as  composite  objects  consisting  of  the 
specification,  a  description,  and  the  implementation.  Using  this  as  the  lowest  level  structural 
granularity  permits  Marvel  to  limit  side-effect  propagation  considerably,  since  other  entities  can 
be  affected  only  when  the  specification  is  changed. 

Decomposition  of  the  target  system  into  separate  objects  at  a  small  grain  places  certain  require¬ 
ments  on  the  object-viewing  and  browsing  capabilities  of  the  environment.  On  one  hand,  a  user 
should  not  be  starved  of  information  as  is  the  case  with  single-level  object  viewers.  For  example, 
viewing  a  module  may  result  in  display  of  only  the  names  of  components,  without  even  an  indica¬ 
tion  of  their  type.  More  context  should  be  provided  to  the  users. 

On  the  other  hand,  a  user  should  not  be  overloaded  with  information,  which  may  lead  to  disorien¬ 
tation  and  confusion.  An  example  of  this  is  the  presentation  of  the  target  system  as  a  single 
textual  unit,  decorated  with  all  available  status  information  —  possibly  encoded  in  a  range  of 
symbols.  A  balance  must  be  struck  as  to  the  amount  of  information  to  be  displayed  at  any  time 
and  the  desire  to  reduce  explicit  querying  for  information.  This  may  change  over  time  as  the 
users  carry  out  different  activities.  For  example,  while  making  major  changes  to  the  system  a  user 
has  little  interest  in  code  generation  status.  Similarly,  when  examining  an  imported  module,  the 


user’s  view  should  be  limited  to  its  specification.  Smile  solves  these  problems  with  distinct  com¬ 
mands  for  different  levels  of  detail,  while  Marvel  includes  an  objectbase  viewing  and  browsing 
capability  supporting  multiple  views  and  multi-level  viewing,  which  makes  best  use  of  available 
screen  space  through  multiple  viewing  panes. 

5  Granularity  of  Processing 

As  previously  discussed,  the  tools  as  well  as  the  users  can  take  advantage  of  multiple  views.  A 
related  issue  is  whether  or  not  the  users  should  have  multiple  Views’  of  the  tools.  The  granularity 
of  processing  determines  the  responsiveness  of  the  environment  as  well  as  the  intelligence  per¬ 
ceived  by  its  users.  Responsiveness  refers  both  to  feedback  to  the  users  regarding  inconsis¬ 
tencies  in  the  target  system  and  to  processing  of  the  target  system  to  derive  other  represen¬ 
tations,  e.g.,  to  prepare  for  execution  or  for  formated  printing.  Marvel  and  other  knowledge- 
based  programming  environments  are  interactive  environments  that  attempt  to  increase  user 
productivity.  This  means  that  each  user  should  get  feedback  while  in  the  context  of  the  problem 
spot;  the  environment  displays  intelligence  by  understanding  the  user’s  notion  of  context  and 
relating  it  to  the  results  of  the  tools. 

This  also  means  that  a  user  should  not  have  to  wait  excessively  for  the  computer  to  complete  its 
share  of  the  work.  This  is  accomplished  by  processing  at  the  appropriate  level  of  granularity  and 
by  processing  opportunistically.  The  availability  of  both  forward  and  backward  chaining  permits 
Marvel  to  perform  activities  any  time  between  when  the  preconditions  are  satisfied  and  when  the 
postconditions  are  required.  Furthermore,  not  all  processing  has  to  be  done  at  the  same  level  of 
granularity.  Granularity  of  processing  that  results  in  feedback  to  the  user  is  strongly  influenced  by 
the  context  and  time  in  which  feedback  is  expected.  Note  that  feedback  may  involve  simple 
visual  cues,  such  as  changing  the  font  of  the  prompt,  rather  than  immediately  dumping  all  the 
error  messages  on  the  user's  display. 

Granularity  of  processing  resulting  mainly  in  derived  entities  such  as  object  code  is  primarily 
influenced  by  the  following  tradeoff.  On  the  one  hand,  we  have  the  possibility  of  processing  many 
small  units,  thus  reducing  the  time  of  processing  one  unit,  yet  causing  possibly  redundant 
processing  of  the  same  unit  when  it  is  frequently  affected  by  changes  to  other  small  units.  On  the 
other  hang,  processing  larger  units  at  less  frequent  intervals  leads  to  the  expense  of  longer 
delays  when  the  users  need  the  results.  In  some  cases,  this  problem  means  exploration  of 
separate  processing  techniques  in  order  to  avoid  processing  of  the  oomplete  target  system.  Ex¬ 
amples  include  linking  in  pieces  through  use  of  indirect  references  [8],  and  formatting  in  pieces  by 
a  document  processor  through  maintenance  of  formatting  context  —  as  is  supported  by 
Scribe  [21], 

Feedback  to  the  users  can  occur  at  several  levels  of  granularity,  where  the  grain  size  chosen  may 
be  different  for  different  kinds  of  analysis.  One  form  of  feedback  is  enforcement  of  a  particular 
kind  of  consistency.  The  most  prominent  example  is  enforcement  of  syntactic  consistency,  as 
done  by  syntax-directed  or  form  editors.  This  is  accomplished  eilher  by  limiting  the  choices  of 


entry  to  acceptable  ones,  e.g.,  by  providing  a  menu  with  the  legal  set  of  constructs,  or  by  im¬ 
mediately  checking  and  rejecting  invalid  entries.  Another  form  of  feedback  is  checking  for  consis¬ 
tency  and  reporting  any  violations,  but  accepting  the  input  into  the  objectbase.  In  this  case, 
Marvel  records  whether  or  not  objects  have  been  checked  for  each  kind  of  consistency  and,  if 
so,  the  results  of  each  analysis. 

During  different  phases  of  development  and  maintenance,  a  user  may  desire  feedback  for  the 
same  kind  of  consistency  at  different  granularity  levels.  For  example,  while  writing  a  new  piece  of 
code,  a  user  does  not  want  to  be  told  repeatedly  about  the  use  of  an  undefined  identifier  until  he 
has  completed  his  activity  with  the  procedure  or  module.  However,  when  carrying  out  minor 
corrections,  more  immediate  feedback  is  desirable.  Marvel  offers  such  flexibility  by  separating 
checking  from  reporting.  In  this  way,  checking  for  a  particular  kind  of  consistency  is  always 
performed  at  the  same  level  of  granularity  —  the  smallest  level  for  which  feedback  is  desired  — 
with  one  set  of  analysis  processes.  Reporting  can  be  realized  by  querying  the  results  of  check¬ 
ing,  and  Marvel  does  this  by  performing  queries  automatically  at  different  times  as  determined 
by  the  reporting  strategy. 

This  behavior  is  in  contrast  to  Smile,  which  initially  performed  compilation  at  the  level  of 
procedures  and  immediately  informed  the  user  of  any  errors.  We  found  this  behavior  unaccept¬ 
able.  Smile  was  modified  to  perform  symbol  resolution  and  type  checking  at  the  procedure  level, 
but  to  apply  compilation  only  to  modules.  Errors  were  no  longer  reported  except  in  response  to 
user  queries,  but  their  detection  was  indicated  by  an  unintrusive  visual  change  in  the  display  that 
remained  until  the  errors  were  corrected. 

6  Conclusions 

The  fundamental  tradeoffs  regarding  granularity  of  logical  entities  and  of  automatic  processing 
demonstrate  the  impact  of  the  choices  of  granularity  on  the  apparent  intelligence  of  an  environ- 
r  "it  as  well  as  on  its  responsiveness  and  performance.  The  most  notable  choices  we  made  for 
ProfessorMarvel  are  notably 

•  A  knowledge-based  programming  environment  can  more  quickly  answer  more  com¬ 
plex  queries  when  it  incrementally  updates  its  analysis  of  the  relationships  among 
logical  entities  of  the  target  software  system  and  also  maintains  these  entities  refined 
to  the  level  of  relationships  among  individual  software  components  rather  than 
among  modules. 

•  An  environment  is  less  intrusive  and  more  informative  when  the  granularity  of 
automatic  processing  is  separated  from  the  granularity  for  automatic  reporting  of  the 
results  of  processing,  and  it  is  not  difficult  to  separate  these  behaviors  for  semantic 
analysis,  compilation  and  other  activities. 

We  believe  that  these  choices  are  also  appropriate  for  most  other  knowledge-based  programming 
environments.  While  Smile  was  targeted  for  C,  we  designed  Marvel  to  support  either  C,  Com- 
monLisp,  or  Ada.  We  also  kept  in  mind  document  formatting  languages  such  as  Scribe  and 
project  management  facilities  such  as  those  found  in  CMS  [16]  and  DSEE  [17].  Thus  our  conclu¬ 
sions  cover  a  wide  range  of  possible  entities  as  well  as  tools. 
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